[State Sync] Add server side implementation of semi-intelligent syncing mode. #5742
Conversation
JoshLind
force-pushed
the
ss_new_mode_3
branch
from
5c39b7c to
c72d40e
Compare
| @@ -1244,6 +1321,63 @@ impl StorageReaderInterface for StorageReader { | |||
| ))) | |||
| } | |||
|
|
|||
| fn get_transactions_or_outputs_with_proof( | |||
There was a problem hiding this comment.
FYI: this is the new logic. Everything else is boilerplate to handle the new request types 😄
| // doesn't fit, return a transaction chunk instead. | ||
| let mut num_output_reductions = 0; | ||
| while num_output_reductions <= max_num_output_reductions { | ||
| let output_list_with_proof = self |
There was a problem hiding this comment.
Is there any concern calling this multiple times will be expensive?
There was a problem hiding this comment.
Yeah, we're currently doing this for all storage calls where the data overflows the max frame size. At worst, I've seen it take a couple seconds (<= 2). There is a task on the storage side to provide better APIs so we don't have to call in like this. Once those land, we can migrate.
| } else if num_outputs_to_fetch == 1 { | ||
| break; // We cannot return less than a single item. Fallback to transactions | ||
| } else { | ||
| increment_network_frame_overflow( |
There was a problem hiding this comment.
This will mean there can be more overflows than responses (because multiple overflows per response). Is this the intention?
There was a problem hiding this comment.
Yeah, this is fine. We have other metrics to track the number (and types) of requests and responses, so using this we can calculate the average number of overflows/retries per request. Does that make sense?
This comment has been minimized.
This comment has been minimized.
This comment has been minimized.
This comment has been minimized.
✅ Forge suite
|
✅ Forge suite
|
Note: most of this PR is just boilerplate and tests. There's probably only 30 lines of interesting code.
Description
This PR adds the server side implementation of a new "semi-intelligent" state syncing mode, where the client (syncing node) requests chunks of transactions or outputs from a peer, and the peer decides which data to return based on whichever is quicker: (i) downloading and applying the outputs; or (ii) downloading and executing the transactions. The trade-off is that outputs are quick to apply (but might require lots of network data), and transactions are slow to execute (but might require much less network data).
The way the storage server on the peer decides which data to send per chunk is through a simple value provided by the client on the request (
max_num_output_reductions), which tells the server that if it needs to reduce the number of outputs being requested more thanmax_num_output_reductionstimes, it should just return transactions. For example: a client requests 2000 outputs in a single chunk and specifiesmax_num_output_reductions = 2. The server will attempt to serve this data, and if it needs to reduce the outputs (halve them) more than2times (i.e., send less than 500 outputs) it will instead fallback to sending transactions for the chunk.Some notes:
max_num_output_reductionsis configurable so that we can tune it. The current default is2.Test Plan
New and existing tests!